Currently this only adds two tests that fail, but I'd like some input as to whether it is a reasonable expectation of an LDP implementation that they would pass.

They beg the question of whether an LDP server should remember the Content-Type of resources that are added to it.

From http://www.w3.org/TR/ldp/#ldpc-container :

5.2.3.6 LDP servers should use the Content-Type request header to determine the request representation's format when the request has an entity body.

The two tests are the same, but one each for 'text/plain' and 'application/json' resources. They

1. Create a resource with that Content-Type (via PUT)
2. Try to GET it with 'Accept: {contentType}'
3. Assert that the response to the GET has 'Content-Type: {contentType}', which fails. Currently the Content-Type response header is 'application/octet-stream; charset=utf-8' (generic), unless the resource path ends in '.json', in which case it's JSON

If these are tests that should pass, then it seems that one way of implementing this would be to automatically create a resource-name.meta resource when resource-name is created/updated (e.g. via PUT). If resource-name is PUT with Content-Type: text/plain, then this also creates resource-name.meta with some body that indicates that the canonical content type of resource-name is text/plain. Then, when someone does GET resource-name with a certain Accept header, ldnode can know whether it can respond with the resource in that Content Type.

Right now resource-name and resource-name.meta files appear to be implicitly used together, but keeping them 'in sync' is expected to be done by the client the api. So this sort of consistency enforcement could, I guess, just be done by a proxy that sits in front of a 'dumb' ldnode.

So the two questions

1. Should these tests pass in an ideal implementation of LFDP?
2. If yes, what's the best way to implement it in ldnode?